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Corporate LAN 

(57) Abstract: Client databases are synchronised by storing a synchronisation engine (10) maintaining a synchronisation table (20) 
of record identifiers and change indicators for records of the client databases. The table (20) is used during a synchronisation session 
and is maintained persistent between sessions. All client databases (DBA-DBD) are synchronised in a session. Values for identifiers 
and change indicators are received from the client databases and are compared with the stored values to determine if a record has 
changed. The current value is thus identified. All of the client databases are updated with current value of a record and updating the 
synchronisation table is updated for a next synchronisation session. 
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"SynchyopisatioA of databases" 

INTRODUCTION 

5 Field of the Invention 

The invention relates to synchronisation of data aaoss multiple databases even if the 
databases have different structures. For example, a contact record in a mobile phone 
database should contain the same data as a record in an email system contact 
1 0 database of the user and referring to the same contact. 

Prior Art Discussion 

Heretofore, synchronisation is often performed by direct point-to-point updating for 

15 two databases. Where more than two databases are involved, synchronisation is 
« 

typically achieved by daisy-chaining point-to-point sessions between pairs of 
databases. This approach, however, suffers from the problems of:- 
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(a) Synchronisation is not guaranteed to be complete since there is always at least 
20 one database that is not present in the process. It can be shown that three or 

more databases can always be in an imsynchronised state irrespective of how 
many times the links in the daisy chain are reapplied. This failure can occur even 
when the data has not been changed by the user; the changes being a result of the 
synchronisation itself. 

25 

(b) Complexity, As the number of clients grows, the number of possible point-to- 
point links increases. For example, five databases have ten different point-to- 
point links. Also, the process involves applying and reapplying links in order to 
ensure that all changes have been propagated within the system. 



30 
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United States Patent Specification No. US5884325 (Oracle) describes synchronising 
shared data between computers having similar database structures. When a 
connection is established updates are propagated from the client to the server and 
vice versa. The server eventually propagates updates to other clients. Because this 
5 arrangement provides the server at the centre of a hub linked to all clients it appears 
to be an improvement over the direct point-to-point method described above. 
However, in this arrangement dients will often be out of synchronisation with each 
other. This has the same drawbacks as other point-to-point synchronisation methods. 

10 The invention is therefore directed towards providing an improved Sjmchronisation 
system and method. 

SUMMARY OF THE TNVRNTTON 

15 According to the invention, there is provided a synchronisation system comprising a 
synchronisation engine comprising means for communication with a plurality of 
dient databases and for updating the dient databases with current data received by a 
client database, characterised in that, 

20 the synchronisation engine comprises means for performing a synchronisation 

session in which all client databases (DBA-DBD) are updated with current 
data. 

Thus, all dient databases are synchronised at the end of the session until the next 
25 session. This is a major benefit for data integrity. 

In one embodiment, said engine comprises means for maintaining a synchronisation 
table storing an identifier and a change indicator for each record of each client 
database, for comparing the stored change indicators wifli those read firom the cUent 
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databases during a synchronisation session, and for maintaining the table in a 
persistent manner between synchronisation sessions. 

In another embodiment, the system comprises a dient interfece associated with each 
5 client database, each dient interface comprising means for providing a universal 
format for transfer of data to and from the engine independentiy of the client 
database format. 

In one embodiment, the synchronisation engine comprises means for prompting user 
10 input of instructions if a conflict arises in which a record has changed in more than 
one cUent database. 

In another embodiment, the engine comprises means for determining that there is a 
conflict if there are diffferences between records at the fidd level. 

15 

In a further embodiment, the engine comprises means for outputting representations 
of the conflicting fields in a universal format. 

In one embodiment, the engine comprises means for adding or ddeting databases as 
20 dients by adding or ddeting corresponding datasets such as columns in the 
synchronisation table. 

In anotiier embodiment, the engine comprises means for maintaining a master 
database of current data. 

25 

In a further embodiment, the engine comprises means for using the master database 
as a cUent database when a client database is temporarily unavailable. 

In one embodiment, the engine comprises means for temporarily masking a dataset 
30 for a temporarily unavailable client database. 
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In another embodiment, the engme comprises means for maintaining a status 
indicator in the synchronisation table to indicate availability status of a 
corresponding client database. 

5 

In one embodiment, the status values include imcreated, unsynchronised, 
synchronised, and null. 

In another embodiment, a client interface comprises means for maintaining an 
10 intermediate database of true values for truncated values in the associated client 
database. 

In a further embodiment, a client interface comprises means for maintaining a 
persistent database to allow transformation to provide a universal format to the 
15 engine. 

In one embodiment, a client interface comprises means for maintaining a 
personalisation table containing a master identifier, a native identifier, an updated 
flag for every associated record, and a current record identifier list, and the client 
20 interface comprises means for using said data to maintain a client database having a 
subset of the records of other client databases. 

According to another aspect, the invention provides a method for synchronising a 
plurality of client databases in a single synchronisation session, the method 
25 comprising the steps of: 

storing a synchronisation table of record identifiers and change indicators for 
records of the client databases; 
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receiving the values for said identifiers and change indicators from the client 
databases, and comparing tiie received values with the stored values to 
determine if a record has changed to determine die current value; and 

5 updating all of the client databases with a current value of a record and 

updating the synchronisation table for a next synchronisation session, 

DETAILED DESCRIPTION OF THE INVENTION 

10 Brief Description of the Drawings 

The invention will be more clearly understood from the following description of 
some embodiments thereof given by way of example only with reference to the 
accompanying drawings in which:- 

15 

Fig. 1 is a schematic representation of a number of databases interconnected 
for synchronisation, 

Fig. 2 is a generalised diagram illustrating the architecture; 

20 

Fig. 3 is a schematic representation of a synchronisation table generated 
during a synchronisation process; 

Figs. 4(a) and 4(b) are together a flow diagram of synchronisation; 

25 

Figs. 5 and 6 are sample tables indicating system states; 
Fig. 7 is a sample conflict resolution dialog; 
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Fig. 8 is a set of sample records and corresponding entries in a 
synchronisation table; 

Fig. 9 is a representation of sync, table columns to handle disconnected 
5 clients; 

Fig. 10 is a representation of handling of truncated fields; 

Fig. 1 1 is a logical view of a transformation operation; and 

10 

Fig. 12 is a representation of personalisation components. 

Description of the Embodiments 

15 Referring to Fig. 1 a user's PC 1 is programmed to perform a process to synchronise 
a database 2 on the PC 1, a database 3 in a server 4, an Internet database 5, and a 
database 6 of a mobile phone 7. This is one example scenario. At a general level 
and referring to F^. 2, synchronisation is performed by a synchronisation system 
comprising: 

20 

a synchronisation engine 10, and 

a client interface (*■ client'*) 11 associated with each application A, B, C, and D 
having an associated API and a database DBA, DBB, DBC, and DBD 
25 respectively. 

For synchronisation there are multiple databases and so the basic architecture is in 
tiie form of a hub with the engine 10 in the centre and a client 1 1 for each database. 
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The engine 10 generates a synchronisation table 20, as shown in Fig. 3. This table 
has a row for each item (such as a contact) and two columns for each database. The 
two columns contain for each item a unique identifier (UID) and a change indicator 
(CI). These two columns are derived directly from the databases. The CI is the "last 
5 modified timestamp" where available, and if not available a Cyclic Redundancy 
Check (CRC) may be generated direcfly from the data having a high probability of 
detecting that a record has changed. 

When synchronising a record across the databases the UID and CI for each of the 
10 corresponding records from each of the databases is stored. They are stored in a 
logically linked manner, so that in future synchronisation sessions the linked records 
can be compared like-with-like'. The synchronisation table contains the UIDs and 
the CIs for all syndironised records in all of the configured cUent databases 
(synchronisation points). Each column in the synchronisation table corresponds to 
15 all of the synchronised records for one of the databases. Each row in the 
synchronisation table corresponds to a record that is linked by synchronisation 
between data stores. The synchronisation table is persistent, i.e. its state is saved 
between synchronisation sessions. 

20 The engine 10 is an independent engine that provides all of the synchronisation 
processing, including duplicate handling, conflict resolution, and overall control of 
the synchronisation process. It inVokes the individual dients 11, and requests from 
them data about the current state of their devices/applications and instructs them to 
write back information to the device/applications. It provides a generalised interface 

25 for each different device or apphcation. The engine 10 is responsible for maintaining 
the synchronisation data. 

Each cUent 11 is aware of the format and API offered by the associated application 
and handles all conununication with it Each chent 11 isolates the engine 10 from 
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the specific detail of how information is stored in the applications. The clients 11 
also provide: 

• Application-specific configuration dialogs. 

• Application-dependent storage of non-synchronisable data, such as voice dialling 
5 tags on phones. This information is managed by the dient 1 1 , 

The APIs are conventional APIs for third party access to content. The 
synchronisation process uses these APIs to read and write information to the 
databases in their own proprietary formats. 

10 

The interface between the engine 10 and the clients 11 defines a common and 
consistent universal format containing all of the fields required for synchronisation. 
The engine 10 stores a master database of all synchronised data in the universal 
format. 

15 

Referring to Figs. 4(a) and 4(b), the synchronisation process uses the CI value firom 
the dients 11 to determine (by checking with the synchronisation table) if there is an 
edit conflict. Resolving the conflict involves writing to the universal (or master) 
database the value from the database having the most recent update as indicated by 
20 the CI. If more than one database has an updated CI then user mput may be 
required. Where a new record is detected the engine 10 creates a new row in the 
sync, table. If the "new" record is a duplicate the engine 10 makes a link to an 
existing record after searching key fields and possibly with user input. Any conflict 
with the new record is resolved as described above, again possibly with user input. 

25 

When the engine 10 has processed all records fi:om all client databases it has an 
updated master database. It then updates the client databases by deleting required 
records, updating edited records, creating new records and applying personalisation 
(described in more detail below). The sync, table is then saved to file. 

30 
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In the above process, tiiere is conflict resolution where a record representing the 
same information has been amended in more than one dient database. This is 
known as a conflict and the records are termed as conflicting records. In the case of 
a conflict, there is a need to enable the user make a decision as to which record 
5 accurately reflects the current data and communicate that decision to the 
synchronisation engine. Furthermore, there may be occasions where a number of 
fields within each record have been modified where the current correct data is in fact 
spread across the conflicting records. In this latter case a simple selection of one of 
the conflicting records as the master would not ensure that the correct information is 
10 written back to each of the client databases as a result of the synchronisation process. 
It is of significant benefit for the user to be able to select individual fields from the 
records in conflict to produce a merged new record, so that all fields in the 
synchronised record are up-to-date at the end of synchronisation. 

15 A conflict can also occur if there is a new record in one of the applications, which is 
being synchronised for the fk$t time, that has been identified to be duplicate of one 
that already exists in the synchronised record set (by using the key fields to identify 
the duplicate). In this case, the non-key fields (i.e. fliose which were not used to 
identify a new contact as an existing one) are candidates for conflict resolution. 

20 

During the synchronisation process, the engine 10 retrieves all of the edited records 
and new records firom all the applications in the universal record format via the 
clients 11. Having all records available in the universal format allows field-level 
conflicts to be detected consistently: 

25 

Where a synchronised record has been edited in more than one apphcation, the 
edited universal record representations are compared field-by-field to determine 
which fields of the record are in conflict. If there are fields in conflict, the conflicting 
fields are identified to the user, via a user interface so that they are able to identify 
30 the correct data, in other words, resolve the conflict. If no conflicting fields are 
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found, because each of the changed fields in each of the conflicting records were 
changed to the same new value(s), tihen there is no conflict to resolve even though 
the records are in conflict. In this latter case, the solution is intelligent enough to 
proceed without the need for user intervention. 

5 

Fig. 5 illustrates the state of the system after the last synchronisation and Fig. 6 
illustrates the state of the system prior to the next synchronisation when the same 
record has been edited in both appUcations. The column marked K is the user's key 
field for the record (i.e. what they would typically use to identify the record; in the 

10 case of a contact database this might be the contact's full name). The 
synchronisation table indicates that the two records in the separate appUcations 
represent the same information. Comparison of the change indicators (CI) for each 
appUcation in the row of the synchronisation table with the values stored in the 
application indicate that the record has changed in both applications. Field by field 

15 comparison indicates that there are two fields in conflict, namely tiie first and the 
forth fields. It is important to note that, though the third field has changed (to 
Kiwis), it is not in conflict as the identical change has been made in both records. It 
should also be noted that the forth field is in conflict even though a change has been 
made to that field in only one of the records. 

20 

In order for the user to be able to resolve the conflicting fields of the records, the user 
must be presented with the information in universal record format fi'om each of the 
conflicting records, which have been collated during the conflict-detection phase. 

25 The user interface for the conflict resolution consists of a PC-based dialogue 
displaying a table view whose columns correspond to the fields of the universal 
record. The header of the table identifies the content of each column. The first 
column of the table identifies for each row of the table where the rows data is derived 
from. The top row of the table view displays the resultant resolved record. This 
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record does not direcdy correspond to any real record in a database; it is the 
'working* record, which the user is resolving. 

The rows in the conflict resolution table view of Fig. 7 show the universal record 
5 representation from each of the applications for the conflicting records. There must 
always be at least two additional rows displayed, since these rows correspond to the 
conflicting records. To assist the user in the conflict resolution process, the columns 
of the table view are re-ordered, so that the fields that are in conflict are displayed on 
the far left: of the table. In addition, the conflicting fields are highlighted in bold to 

10 distinguish them from the non-conflicting fields. This quickly draws the attention of 
the user to the fields whidi are in conflict, so that they may resolved with the 
minimum difficulty. The user chooses the most up-to-date fields from the conflicting 
options, by clicking direcdy on the field value required in the table view. This causes 
the field value in the resolved record (displayed in the top row) to be updated to this 

1 5 last selected value. 

When the user has completed merging the conflicting records, he positively aflBrms 
die merge (by clicking on an OK button). This causes the fields currently displayed 
in the top row to be stored in the master database as the 'resolved record', and 
20 subsequenfly to be written by each of the clients to their respective applications. 

There is an arrow head to the left: of each of the rows representing conflicting 
records. This is a row seleaor button enabling the user to select a whole row as the 
row to be used. 

25 

The above describes the, case where the same field is updated in all conflicting 
records to exacfly the same value and fliis means that there is in fact no conflict to be 
resolved. There is one further case where there is no conflict to be resolved, even 
when a conflicting record is detected (i.e. the same record in multiple apphcations 
30 has been edited). This case occurs when the different applications support a different 
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subset of fidds of the universal record. Fig. 8 illustrates this. In Fig. 8 we see that the 
field diange in Apphcation A* does not appear in Application B', and similarly the 
field change in Application B* does not occur in apphcation A*. In this instance, a 
single merged universal record can be derived fi'om the information in both the 
5 conflicting records without the need for user intervention. 

Thus, the invention provides the following features: 

Full field-level conflict resolution, with the ability to merge up-to-date fields 
10 firom record edits in difierent data sources. 

Ability to detect and handle the situation where identical changes have been 
made to the conflicting records and merge them without die need for user 
interaction. 

15 

Ability to detect and handle situations where changes have been made to 
conflicting records containing non-intersecting sets of changed fields. Again, 
in tibis instance, there would be no need for user interaction. 

20 Addition and removal of cUent databases is achieved in a simple manner 

wifliout destabilisation of the system. 

When a new client is configured, a new column is added to the sync, table. The 
entries of tihie new column are initialised to have a synchronisation state of 
25 *unsynchroniseci'. During the next synchronisation, this *unsynchronised' state 
triggers the engine 10 to synchronise all the entries in the master database with the 
newly configured data store. When a client is removed, a column is removed from 
the table. This has no fiirther effect on the synchronisation process, apart from 
reducing the number of client databases to be synchronised by one. 



30 



wo 01/90933 




:P01/05869 



-13. 

The invention also handles the situation where one of the clients is temporarily 
unavailable. This might occur, for example, if one of the databases to be 
synchronised happens to be a handheld device for which the battery has expired, or if 
the connection to the database is unreliable, as it might be for an Internet-based 
5 database. In such a case, it would be highly inconvenient if the unavailability of one 
of the configured databases were to prevent the synchronisation of the remaining 
databases. Provision of the synchronisation table together with the master database 
allows for clients to be temporarily unavailable during any given synchronisation. 
By masking out one of the columns of the table, thus hiding it from the 
10 synchronisation process, synchronisation of all the remaining available databases can 
continue. The existence of the master database ensures that the overall record-set is 
always available in universal format. When the databases becomes available again 
for sjmchronisation, its column of the table becomes visible to the engine, and its 
data set is synchronised. 

15 

To support discomectable clients, the synchronisation table also contains a status 
• field in the table, which is used by the engine 10 to determine the required action to 
take, as shown in Fig. 9. The status table entry may take on one of the following 
values: UNCREATED, UNSYNCED, SYNCED, or NULL. 

20 

If an attempt is made to create a record in a dient 11 which is disconnected, the 
create fails, and status is set to UNCREATED. This records the feet that it failed, so 
that on subsequent synchronisation sessions, the create can be re-tried. If an attempt 
is made to edit a record in a client 11 which is disconnected, the edit fails, and the 
25 status is set to UNSYNCED. This records the fact that it failed, so that on 
subsequent synchronisations, the edit can be re-tried. If the client 11 is connected, so 
that creates/edits succeed, tiae status is set to SYNCED, 

If a record is deleted in another (connected) client 11, the engine logic decides to 
30 propagate the delete across all clients 11. For all successfiil deletes, the 
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corresponding synchronisation table entry status is set to NULL. If one of the clients 
1 1 is disconnected at the point the record delete request is made, the delete fails, and 
the status is set to UNSYNCED. Because the synchronisation table row is not 
removed from the table until all entries' status is NULL (indicating successful 
5 deletions), the engine is able to re-try the deletion. 

The NULL status is also used as part of a personalisation solution; if a table entry's 
status for an external client 11 is NULL, and the status for the corresponding entry in 
the column for the master database is non-NULL, then the entry for the external 
1 0 client 1 1 represents a record that is excluded from the personalisation set. 

This technique for handling disconnected clients is equally appUcable to the case 
where the database is physically unavailable, or where the user has elected to omit a 
given database from the synchronisation. When configuring dients 11, there are 
15 three options available: (a) always synchronise the database, (b) prompt the user for 
whether to synchronise the database, of (c) never synchronise the database. 

Thus, the invention provides the ability for the user to control, at synchronisation 
time, flie database (clients) that will be synchronised. It also provides the ability to 
20 complete simultaneous multi-point synchronisation across a set of applications when 
one or more are not available to participate in the synchronisation. On the next time 
an application re-joins the synchronisation process, to be able to pickup "pending 
changes" from previous synchronisation sessions. 

25 In the multipoint synchronisation process the aim is to ensure each participating 
database maintains as faithful a copy of the information stored in each other 
database as possible. In the situation where the structures of the different datastores 
differ, this may involve some transformation in the format of the data. There may 
also be limits on the faithfulness of the data representation imposed by the size 

30 limitations of the storage structures in the different datastores. In most cases when 
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synchronising information in PC, Server or Internet based databases the size 
limitation imposed by different databases do not practically affect die 
synchronisation as the fields are usually sized to cater for the majority of data that a 
user might use. Even if tiiere is some truncation tins usually occurs in a sufficientiy 
5 small amount of cases to have neghgible affect. 



However, when providing multipoint synchronisation for mobile devices, a very real 
problem is faced. A typical mobile phone may limit the storage of a name in its 
contact datastore to say 12 characters. Synchronising a PC database such as 
1 0 Outiook^^ to phone and back again presents a potential problem as illustrated below: 



Original record in Outlook™ 



Key 


Name 


Number 


A 


Samantha Fielding 


1-555-457-7845 



Resulting record in phone (12 character name restriction) 



Key 


Name 


Number 


A 


Samantlia Fie 


1-555-457-7845 



15 



Now, if a user changes the record on the phone, amending the number to 1-555-457- 
8888, the phone's record would read: 

New record in phone 



Key 


Name 


Number 


A 


Samantha Fie 


1-555-457-8888 



20 



Using standard record-level synchronisation, the Outiook™ record would liien 
become 



Key I Name 



Number 
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Samantha Fie 



1-555-457-8888 



This reduces the Outlook™ record to the storage limitation of the phone. Without 
special handling all datastores involved in the synchronisation risk being limited to 
the storage capabilities of the phone (for those fields stored on the phone). Referring 
5 to Fig. 10, in order to ensure correct synchronisation a client 11 maintains a 
persistent Intermediate Datastore to store a copy of the original xmiversal record (or 
at least a copy of all the fields that could be subject to truncation) and its 
corresponding truncated data. This enables the dient to detect changes to the 
truncated data in the application datastore by comparing the truncated data currently 
10 in the application datastore with the truncated data that was stored in the 
Intermediate Datastore. 



The synchronisation is driven by the engine 10 requesting clients to read and write 
records to the databases. In a write request the clients are responsible for translating 
15 the record in imiversal record format as given by the engine 10 into the application's 
record format and conversely, in a read request the clients 11 are responsible for 
translating the record firom the applications format to the universal record format. 
To handle truncation, the following additional processing is required (referring to 
Fig. 10 for nomenclature). 

20 

Basic write request fi-om the engine. 



Convert universal record format to database format. 

25 Create a record in the client's Intermediate Datastore, containing for each 

field that could be truncated, a copy of the pre-converted field data (true 
value) and a copy of the field data afi:er conversion and possible truncation 
(converted value). 
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Write the record in database format to the database. 

Basic read request &om engine 

5 Read record from database 

Read corresponding record from Intermediate Datastore. 
Convert record to universal record format 

10 For each field that could be truncated, compare the value returned from the 

application with the converted value stored in the client's Intermediate 
Datastore. If the values match, replace the field in the universal record with 
true value from the client's Intermediate Datastore. 

1 5 Pass the universal record back to the engine. 

This process prevents the loss of data through the propagation of truncated data 
during the synchronisation process. 

20 Fig. 11 illustrates use of the Intermediate Datastore in more detail. The universal 
record structure Intermediate Datastore is represented on the left and the application- 
specific record structure is represented on the right. The client is responsible for 
translating the common fields in both records from one format to the other. Fig. 11 
shows the universal record, having a unique id (UID) and fields Y, Z, and A - G. 

25 The application record has a corresponding UID and fields A - H. Both records 
have in common the UID and common fields A - G, 

Fields A - D and F have the same representation in bodi records, so the dient needs 
to do no processing other than copy one to the other. 

30 
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Field E is represented in the ai^lication datastore in a different way to the universal 
record but has a reversible transformation (R) between the two representations. All 
the dient needs to do is perform this transformation in the appropriate direction 
when requested to read or write a record by the engine. An example of this might be 
5 a priority field, represented in the universal contact record as values 1,2 or 3 and is 
represented in the appUcation's datastore as "high", "medium" or "low". 

Field G has a one-way transformation (T) from G to G". In this case universal 
representation and the apphcation specific representation need to be stored in the 

10 chent's Intermediate Datastore during a write operation to the apphcation. This 
information is used during a read operation to determine whether field G" has been 
changed by flie user. If it has not, The chent's Intermediate Datastore's copy G is 
used to construct the universal record using its correct value (i.e. before 
transformation T has been appUed). This process enables individual cUents 11 to 

IS transform the data to a ,more suitable format whilst ensuring that any unedited 
transformed data is not propagated to other clients. 

When synchronising records between a number of datastores the synchronisation 
engine ensures that, at the end of the process, each datastore contains a 
20 representation of all of flie records, for example, each datastore would contain n 
records. 

There are a number of scenarios in which it would be beneficial for one or more of 
these datastores to contam only a subset of die entire record set. These include, but 
25 are not hmited to: 



a. Limited storage capability. The datastore does not have the capacity to store all 
of the records. This can typically occur with devices such as mobile phones. 
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b. Data manageability. A large set of records may degrade die performance or 
usability of the application that manages them. 

c. Minimising synchronisation time. Interaction with a data store may be time- 
5 consuming and so reducing the quantity of data can improve the speed of 

synchronisation. 

d. Relevant data. A Personal Digital Assistant (PDA) user may only want records 
associated with their next business trip. 

10 

In this specification, the ability to synchronise a subset of records is termed Subset 
Personalisation. Witii regard to multipoint synchronisation, the engine is responsible 
for the actual synchronisation functionality such as conflict resolution and dupUcate 
handling. A cHent that supports Subset PersonaUsation is responsible for managing 
1 5 the subset The following describes how such a client can be implemented. 

A requirement is for there to be a database containing all records in the 
synchronisation set. This database needs to be accessible at every synchronisation 
session. It also needs to contain records that support all universal field data. The 
20 master database satisfies these requirements. 

The client 11 uses a Personalisation Table and a Current UID List. The Current 
UID List contains a list of the UIDs of aU of the records in the native database. The 
list is generated at the start of a synchronisation session and is discarded at the end of 

25 the session. The Personalisation Table contams fliree columns - Master UID, Native 
UID and Updated. The table has a row for every entry in the Personalisation subset. 
The Master UID value is the UID of the record in the Master database. The Native 
UID value is the UID of the corresponding record in the native database. The 
Update value is a flag denoting whether an entry has changed. The table is persistent 

30 between sync. Sessions. Fig. 12 illustrates these components. 
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Subset Personalisation is achieved during synchronisation as follows. At the start of 
die process, the client initialises each value in the Updated column of the 
Personalisation Table to FALSE. It extracts a list of the UIDs and CIs of all of the 
5 records in the native database. Using these values, it updates the Change Status 
column in the sync table accordingly. It also creates the Current UID List from all of 
the UIDs in the native database. 

For every new record that it finds, the client adds a new row to the Personalisation 
10 Table, setting the Native UID value to that of die new record and setting the 
Updated flag to FALSE. The Master UID value is set to NULL. During the 
synchronisation process, the engine may instruct the client to Delete, Edit or Create 
records. The dient processes these instructions as follows: 

15 Delete Record 

The dient uses the supplied Native UID to find the entry in the Personalisation 
Table and removes that row. 

Edit Record 

20 The dient uses the supplied Native UID to find the entry in the Personalisation 
Table and sets the Update value of the entry to TRUE. 

Create Record. 

The dient does nothing. 

25 

When all changes have been applied to all of the clients, the engine instructs each 
client to personalise its data set (if supported). When the client detects new records, it 
added new rows to the Personalisation Table with the Master UID set to NULL 
(since the Master UID is obviously unknown at that time). At this stage, as part of 
30 the synchronisation process, the UIDs of the new records will have been inserted at 
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the appropriate positions in the Sync Table. The client now searches the 
Personalisation Table for these entries. For each one that it finds, it:- 

a. reads liie Native UID of Ae entry 



b. uses the Native UBD to search the Sync Table to determine where the entry was 



c. retrieves the Master UID for that Sync Table entry, and 

10 

d. applies the Master UID to the Personalisation Table row. 

The set of records that make up the Personalisation Subset can be specified in a 
number of ways. These include, but are not limited to: 

15 

a. User selection. The user is provided with a list of all of the records and can select 
those records that are to make up the subset. 

b. Rule based selection. The user sets some criteria that a record must satisfy for 
20 inclusion in the subset e.g. Country = USA. 

A key diflference between tiiese two methods is that, in the former, the 
Personalisation Set can vary during the process due to deletions in any dient or new 
records in the native database. However in the latter metiiod, the Personalisation Set 
25 can vary during the process as a result of deletions, edits jand new records from any 
client. At this stage, the master database contains all of the records with the latest 
data. A client using the rule based method now needs to update its Personalisation 
Table entries. For each entry in the Personalisation Table, the client: 

30 a. reads the Master UID, 



5 



applied, 
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b. retrieves the associated record from the Master database, and 

c. checks whether the rule criteria are satisfied. If not, that entry is removed from 



The client now reads each record in the master database. For each record, it checks 
whether the rule criteria are satisfied. If they are, and the entry is not currently in the 
set, the client creates a new entry in the Personalisation Table, The new entry has the 
10 Master UID value applied, the Updated field set to FALSE and the Native UID 
value set to NULL. The Native UID value will be set when the record is created in 
the native database. 

At diis point, 

15 

a. the Personalisation Table is now fiiUy populated with the correct data and 
contains an entry for each record in the subset. 

b. the Master database contains all of the records with the latest data. 

20 

c. the Current UID List contains a list of the UIDs of all of the records currently in 
the native database. 

The client now applies the actions (Delete, Edit, Create) needed for the 
25 Personalisation Subset. 

Delete 

If a Native UID in the Current UID List does not have a corresponding entry in the 
Personalisation Table then that record is deleted in the Native database. 



5 



the Personalisation Table. 



30 
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Create 

If a Native UID value in the Personalisation Table is NULL then a new record is 
required in the Native database. The client 11 uses the Master UID entry to retrieve 
flie correct record from the Master database and creates a corresponding record in 
5 the native database. The UID of the newly aeated record is stored in the Native UID 
column. 

Edit 

If a Native UID in the Current UBD List has a corresponding entry in the 
10 Personalisation Table and the Update value is TRUE then that record needs to be 
edited in the native database. The client uses the Master UID entry to retrieve the 
correct record from the Master database and updates the corresponding record in the 
native database. 

15 When all actions have been applied, the subset of records are synchronised and the 
synchronisation process is complete. 

It will be appreciated that the invention achieves the following advantages. 

20 Ability to control the records from the overall available set of records which 

are required to be synchronised to any given data store, by using either 
explicit selection or rules based selection. 

Enabling datastores of limited storage ability to be synchronized with large 
25 data stores. 

Improving data managability. 



Reducing synchronisation time. 
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Allowing the user to synchronize only relevant data. 

Having a (weU thought out) defined universal record format at the outset enables a 
developer to provide all the mappings and transformations within the engine during 
5 the coding stage and only needs to require the user to map fields during the setup of 
the synchronisation in extreme cases. This reduces the risk of user error and 
confusion. It also simplifies the process of user configuration of the synchronisation 
process. 

10 Furthermore, by ensuring that the engine stores its data in the master datastore in the 
universal record format, no intemal transformations are required and all 
comparisons required to do the synchronisation are independent of the applications 
being synchronised. This enables the incremental development and addition of new 
clients without requiring any change to the engine. 

15 

Exposing the universal record format to the user through the user interface has a 
number of additional benefits; nainely: 

• The user can get a view of his synchronised data in a common format. 

• The user can see all data that is partaking in the synchronisation (viewing it 
20 through the interface of one of the Application may not expose all the 

information partaking in the synchronisation.) 

• When displaying conflicts in records from two or more applications, the user is 
able to see the conflicts in a common format. 

25 Thus, the invention enables the incremental adding of clients to a multi-point 
synchronisation process without the need to: 

• test every other synchronisation client, 

• be aware of any odier record format other than the universal record format, and 

• to amend the core synchronisation product. 
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The invention is not limited to the embodiments described but may be varied 
construction and detail. 
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Clainris 



1. 

5 

10 

2. 

15 



3. 

20 



4. 

25 



5. 

30 



A synchronisation system comprising a synchronisation engine comprising 
means for conamunication with a plurality of client databases and for updating 
the client databases with current data received by a client database, 
characterised in that, 

the synchronisation engine (10) comprises means for performing a 
synchronisation session in which all dient databases (DBA-DBD) are updated 
with current data. 

A synchronisation system as claimed in daim 1, wherein said engine comprises 
means for maintaining a synchronisation table (20) storing an identifier and a 
change indicator for each record of each client database, for comparing the 
stored change indicators with those read from the client databases during a 
synchronisation session, and for maintaining the table in a persistent manner 
between synchronisation sessions. 

A synchronisation system as claimed in claim 2, wherein the system comprises 
a client interface (11) associated with each dient database, each dient interface 
comprising means for providing a universal format for transfer of data to and 
from the engine independendy of the client database format. 

A synchronisation system as claimed in any preceding claim, wherein the 
synchronisation engine (10) comprises means for prompting user input of 
instructions if a conflict arises in which a record has changed in more than one 
client database. 

A synchronisation system as daimed in daim 4, wherein the engine (10) 
comprises means for deterniiiiing that there is a conflict if there are differences 
between records at the fidd level 



wo 01/90933 




7EP01/05869 



-27- 



10 



15 



20 



6. A synchronisation system as claimed in daims 4 or 5, wherein the engine (10) 
comprises means for outputdng representations of the conflicting fields in a 
universal format. 

7. A synchronisation system as claimed in any preceding claim, wherein the 
engine (10) comprises means for adding or deleting databases as clients by 
adding or deleting corresponding datasets such as columns in the 
synchronisation table. 

8. A synchronisation system as claimed in any preceding claim, wherein the 
engine (10) comprises means for maintaining a master database of current data. 

9. A synchronisation system as claimed in daim 8, wherein the engine comprises 
means for using the master database as a client database when a client database 
is temporarily unavailable. 

10. A synchronisation system as daimed in claim 9, wherein the engine (10) 
comprises means for temporarily masking a dataset for a temporarily 
unavailable dient database. 

11. A synchronisation system as claimed in claim 10, wherein the engine (10) 
comprises means for maintaining a status indicator (5) in the synchronisation 
table to indicate availability status of a corresponding dient database. 

12. A synchronisation system as daimed in claim 11, wherein the status values 
include unaeated, unsynchronised, synchronised, and null. 
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13. A synchronisation system as daimed in any preceding claim, wherein a client 
interface comprises means fqr maintaining an intermediate database of true 
values for truncated values in the associated client database. 

14. A synchronisation system as claimed in any preceding claim, wherein a client 
interface comprises means for maintaining a persistent database to aUow 
transformation to provide a universal format to the engine. 

15. A synchronisation system as daimed in any preceding claim, wherein a client 
interface comprises means for maintaining a personalisation table containing a 
master identifier, a native identifier, an updated flag for every associated record, 
and a current record identifier list, and the client interface comprises means for 
using said data to maintain a dient database having a subset of the records of 
other dient databases. 

16. A method for synchronising a plurality of dient databases in a single 
synchronisation session, the metiiod comprising tihe steps of: 

storing a synchronisation table of record identifiers and diange indicators for 
records of the dient databases; 

receiving the values for said identifiers and change indicators fi-om the dient 
databases, and comparing the received values with the stored values to 
determine if a record has changed to determine the current value; and 

updating all of the client databases with a current value of a record and 
updating the synchronisation table for a next synchronisation session. 

17. A computer program product comprising software code for performing the 
method of daijn 16 when executing on a digital computer. 
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